diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index ae91252..7728104 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,6 +1,6 @@
 Please do not submit a Pull Request via github.  Our project makes use of
 mailing lists for patch submission and review.  For more details please
-see https://www.denx.de/wiki/U-Boot/Patches
+see https://u-boot.readthedocs.io/en/latest/develop/sending_patches.html
 
 The only exception to this is in order to trigger a CI loop on Azure prior
 to posting of patches.
diff --git a/doc/develop/index.rst b/doc/develop/index.rst
index f7ee09d..72332f7 100644
--- a/doc/develop/index.rst
+++ b/doc/develop/index.rst
@@ -11,6 +11,7 @@
 
    codingstyle
    designprinciples
+   patman
    process
    release_cycle
    system_configuration
diff --git a/doc/develop/process.rst b/doc/develop/process.rst
index 388945c..0fa0143 100644
--- a/doc/develop/process.rst
+++ b/doc/develop/process.rst
@@ -108,6 +108,8 @@
   In U-Boot, ``"-rc1"`` will only be released after all (or at least most of
   the) patches that were submitted during the merge window have been applied.
 
+.. _custodians:
+
 Custodians
 ----------
 
@@ -127,31 +129,88 @@
 patch will be accepted anyway, or if the patch should be
 reworked/resubmitted, or if it was rejected.
 
+Review Process, Git Tags
+------------------------
+
+There are a number of *git tags* that are used to document the origin and the
+processing of patches on their way into the mainline U-Boot code. The following
+is an attempt to document how these are usually handled in the U-Boot project.
+
+In general, we try to follow the established procedures from other projects,
+especially the Linux kernel, but there may be smaller differences. For
+reference, see the Linux kernel's `Submitting patches
+<https://www.kernel.org/doc/html/latest/process/submitting-patches.html>`_
+document.
+
+.. _dco:
+
+* Signed-off-by: the *Signed-off-by:* is a line at the end of the commit
+  message by which the signer certifies that they were involved in the development
+  of the patch and that they accept the `Developer Certificate of Origin
+  <https://developercertificate.org/>`_. Following this and adding a
+  ``Signed-off-by:`` line that contains the developer's name and email address
+  is required.
+
+   * Please note that in U-Boot, we do not add a ``Signed-off-by`` tag if we
+     just pass on a patch without any changes.
+
+   * Please note that when importing code from other projects you must say
+     where it comes from, and what revision you are importing. You must not
+     however copy ``Signed-off-by`` or other tags.
+
+* Everybody who can is invited to review and test the changes. Typically, we
+  follow the same guidelines as the Linux kernel for `Acked-by
+  <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by>`_
+  as well as `Reviewed-by
+  <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
+  and similar additional tags.
+
+* Reviewed-by: The patch has been reviewed and found acceptible according to
+  the `Reveiwer's statement of oversight
+  <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight>`_.
+  A *Reviewed-by:* tag is a statement of opinion that the patch is an
+  appropriate modification of the code without any remaining serious technical
+  issues. Any interested reviewer (who has done the work) can offer a
+  *Reviewed-by:* tag for a patch.
+
+* Acked-by: If a person was not directly involved in the preparation or
+  handling of a patch but wishes to signify and record their approval of it
+  then they can arrange to have an *Acked-by:* line added to the patch's
+  changelog.
+
+* Tested-by: A *Tested-by:* tag indicates that the patch has been successfully
+  tested (in some environment) by the person named. Andrew Morton: "I think
+  it's very useful information to have. For a start, it tells you who has the
+  hardware and knows how to build a kernel. So if you're making a change to a
+  driver and want it tested, you can troll the file's changelog looking for
+  people who might be able to help."
+
+* Reported-by: If this patch fixes a problem reported by somebody else,
+  consider adding a *Reported-by:* tag to credit the reporter for their
+  contribution. Please note that this tag should not be added without the
+  reporter's permission, especially if the problem was not reported in a public
+  forum.
+
+* Cc: If a person should have the opportunity to comment on a patch, you may
+  optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then
+  automatically arrange that they receives a copy of the patch when you submit it
+  to the mainling list. This is the only tag which might be added without an
+  explicit action by the person it names. This tag documents that potentially
+  interested parties have been included in the discussion.
+  For example, when your change affects a specific board or driver, then makes
+  a lot of sense to put the respective maintainer of this code on Cc:
+
 Work flow of a Custodian
 ------------------------
 
 The normal flow of work in the U-Boot development process will look
 like this:
 
-#. A developer submits a patch via e-mail to the u-boot mailing list.  In
-   U-Boot, we make use of the `Developer Certificate of Origin
-   <https://developercertificate.org/>`_ that is common in other projects such
-   as the Linux kernel.  Following this and adding a ``Signed-off-by:`` line
-   that contains the developer's name and email address is required.
-
-   * Please note that when importing code from other projects you must say
-     where it comes from, and what revision you are importing. You must not
-     however copy ``Signed-off-by`` or other tags.
-
-#. Everybody who can is invited to review and test the changes.  Typically, we
-   follow the same guidelines as the Linux kernel for `Acked-by
-   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by>`_
-   as well as `Reviewed-by
-   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`_
-   and similar additional tags.
-
 #. The responsible custodian inspects this patch, especially for:
 
+   #. The commit message is useful, descriptive and makes correct and
+      appropraite usage of required *git tags*.
+
    #. :doc:`codingstyle`
 
    #. Basic logic:
diff --git a/doc/develop/sending_patches.rst b/doc/develop/sending_patches.rst
index 0542ade..1730756 100644
--- a/doc/develop/sending_patches.rst
+++ b/doc/develop/sending_patches.rst
@@ -3,14 +3,452 @@
 Sending patches
 ===============
 
-.. toctree::
-   :maxdepth: 2
+*Before you begin* to implement any new ideas or concepts it is always a good
+idea to present your plans on the `U-Boot mailing list
+<https://lists.denx.de/listinfo/u-boot>`_. U-Boot supports a huge amount of
+very different systems, and it is often impossible for the individual developer
+to oversee the consequences of a specific change to all architectures.
+Discussing concepts early can help you to avoid spending effort on code which,
+when submitted as a patch, might be rejected and/or will need lots of rework
+because it does not fit for some reason. Early peer review is an important
+resource - use it. Being familiar with the :doc:`process` is also important.
 
-   patman
+A good introduction how to prepare for submitting patches can be found in the
+LWN article `How to Get Your Change Into the Linux Kernel
+<http://lwn.net/Articles/139918/>`_ as the same rules apply to U-Boot, too.
 
+Using patman
+------------
 
 You can use a tool called patman to prepare, check and sent patches. It creates
 change logs, cover letters and patch notes. It also simplified the process of
 sending multiple versions of a series.
 
 See more details at :doc:`patman`.
+
+General Patch Submission Rules
+------------------------------
+
+* All patches must be sent to the `u-boot@lists.denx.de
+  <https://lists.denx.de/listinfo/u-boot>`_ mailing list.
+
+* If your patch affects the code maintained by one of the :ref:`custodians`, CC
+  them when emailing your patch. The easiest way to make sure you don't forget
+  this even when you resubmit the patch later is to add a ``Cc: name
+  <address>`` line after your ``Signed-off-by:`` line (see the example below).
+
+* Take a look at the commit logs of the files you are modifying. Authors of
+  past commits might have input to your change, so also CC them if you think
+  they may have feedback.
+
+* Patches should always contain exactly one complete logical change, i. e.
+
+   * Changes that contain different, unrelated modifications shall be submitted
+     as *separate* patches, one patch per changeset.
+
+   * If one logical set of modifications affects or creates several files, all
+     these changes shall be submitted in a *single* patch.
+
+* Non-functional changes, i.e. whitespace and reformatting changes, should be
+  done in separate patches marked as ``cosmetic``. This separation of functional
+  and cosmetic changes greatly facilitates the review process.
+
+* Some comments on running :doc:`checkpatch.pl <checkpatch>`:
+
+   * Checkpatch is a tool that can help you find some style problems, but is
+     imperfect, and the things it complains about are of varying importance.
+     So use common sense in interpreting the results.
+
+   * Warnings that clearly only make sense in the Linux kernel can be ignored.
+     This includes ``Use #include <linux/$file> instead of <asm/$file>`` for
+     example.
+
+   * If you encounter warnings for existing code, not modified by your patch,
+     consider submitting a separate, cosmetic-only patch -- clearly described
+     as such -- that *precedes* your substantive patch.
+
+   * For minor modifications (e.g. changed arguments of a function call),
+     adhere to the present codingstyle of the module. Relating checkpatch
+     warnings can be ignored in this case. A respective note in the commit or
+     cover letter why they are ignored is desired.
+
+* Send your patches as plain text messages: no HTML, no MIME, no links, no
+  compression, no attachments. Just plain text. The best way the generate
+  patches is by using the ``git format-patch`` command. Please use the
+  ``master`` branch of the mainline U-Boot git repository
+  (``https://source.denx.de/u-boot/u-boot.git``) as reference, unless (usually
+  late in a release cycle) there has been an announcement to use the ``next``
+  branch of this repository instead.
+
+* Make sure that your mailer does not mangle the patch by automatic changes
+  like wrapping of longer lines etc.
+  The best way to send patches is by not using your regular mail tool, but by
+  using either ``git send-email`` or the ``git imap-send`` command instead.
+  If you believe you need to use a mailing list for testing (instead of any
+  regular mail address you own), we have a special test list for such purposes.
+  It would be best to subscribe to the list for the duration of your tests to
+  avoid repeated moderation - see https://lists.denx.de/listinfo/test
+
+* Choose a meaningful Subject: - keep in mind that the Subject will also be
+  visible as headline of your commit message. Make sure the subject does not
+  exceed 60 characters or so.
+
+* The start of the subject should be a meaningfull tag (arm:, ppc:, tegra:,
+  net:, ext2:, etc)
+
+* Include the string "PATCH" in the Subject: line of your message, e. g.
+  "[PATCH] Add support for feature X". ``git format-patch`` should automatically
+  do this.
+
+* If you are sending a patch series composed of multiple patches, make sure
+  their titles clearly state the patch order and total number of patches (``git
+  format-patch -n``). Also, often times an introductory email describing what
+  the patchset does is useful (``git format-patch -n --cover-letter``). As an
+  example::
+
+   [PATCH 0/3] Add support for new SuperCPU2000
+      (This email does not contain a patch, just a description)
+   [PATCH 1/3] Add core support for SuperCPU2000
+   [PATCH 2/3] Add support for SuperCPU2000's on-chip I2C controller
+   [PATCH 3/3] Add support for SuperCPU2000's on-chip UART
+
+* In the message body, include a description of your changes.
+
+   * For bug fixes: a description of the bug and how your patch fixes this bug.
+     Please try to include a way of demonstrating that the patch actually fixes
+     something.
+
+   * For new features: a description of the feature and your implementation.
+
+* Additional comments which you don't want included in U-Boot's history can be
+  included below the first "---" in the message body.
+
+* If your description gets too long, that's a strong indication that you should
+  split up your patch.
+
+* Remember that there is a size limit of 100 kB on the mailing list. In most
+  cases, you did something wrong if your patch exceeds this limit. Think again
+  if you should not split it into separate logical parts.
+
+Attributing Code, Copyrights, Signing
+-------------------------------------
+
+* Sign your changes, i. e. add a *Signed-off-by:* line to the message body.
+  This can be automated by using ``git commit -s``. Please see the
+  :ref:`Developer Certificate of Origin <dco>` section for more details here.
+
+* If you change or add *significant* parts to a file, then please make sure to
+  add your copyright to that file, for example like this::
+
+   (C) Copyright 2010  Joe Hacker <jh@hackers.paradise.com>
+
+	  Please do *not* include a detailed description of your
+	  changes. We use the *git* commit messages for this purpose.
+
+* If you add new files, please always make sure that these contain your
+  copyright note and a GPLv2+ SPDX-License-Identifier, for example like this::
+
+   (C) Copyright 2010  Joe Hacker <jh@hackers.paradise.com>
+
+   SPDX-License-Identifier:<TAB>GPL-2.0+
+
+* If you are copying or adapting code from other projects, like the Linux
+  kernel, or BusyBox, or similar, please make sure to state clearly where you
+  copied the code from, and provide terse but precise information which exact
+  version or even commit ID was used. Follow the ideas of this note from the
+  Linux "SubmittingPatches" document::
+
+   Special note to back-porters: It seems to be a common and useful practice
+   to insert an indication of the origin of a patch at the top of the commit
+   message (just after the subject line) to facilitate tracking. For instance,
+   here's what we see in 2.6-stable :
+
+	 Date:	Tue May 13 19:10:30 2008 +0000
+
+		  SCSI: libiscsi regression in 2.6.25: fix nop timer handling
+
+		  commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream
+
+   And here's what appears in 2.4 :
+
+	 Date:	Tue May 13 22:12:27 2008 +0200
+
+		  wireless, airo: waitbusy() won't delay
+
+		  [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a]
+
+Whatever the format, this information provides a valuable help to people
+tracking your trees, and to people trying to trouble-shoot bugs in your
+tree.
+
+Commit message conventions
+--------------------------
+
+Please adhere to the following conventions when writing your commit
+log messages.
+
+* The first line of the log message is the summary line. Keep this less than 70
+  characters long.
+
+* Don't use periods to end the summary line (e.g., don't do "Add support for
+  X.")
+
+* Use the present tense in your summary line (e.g., "Add support for X" rather
+  than "Added support for X"). Furthermore, use the present tense in your log
+  message to describe what the patch is doing. This isn't a strict rule -- it's
+  OK to use the past tense for describing things that were happening in the old
+  code for example.
+
+* Use the imperative tense in your summary line (e.g., "Add support for X"
+  rather than "Adds support for X"). In general, you can think of the summary
+  line as "this commit is meant to 'Add support for X'"
+
+* If applicable, prefix the summary line with a word describing what area of
+  code is being affected followed by a colon. This is a standard adopted by
+  both U-Boot and Linux. For example, if your change affects all mpc85xx
+  boards, prefix your summary line with "mpc85xx:". If your change affects the
+  PCI common code, prefix your summary line with "pci:". The best thing to do
+  is look at the "git log <file>" output to see what others have done so you
+  don't break conventions.
+
+* Insert a blank line after the summary line
+
+* For bug fixes, it's good practice to briefly describe how things behaved
+  before this commit
+
+* Put a detailed description after the summary and blank line. If the summary
+  line is sufficient to describe the change (e.g. it is a trivial spelling
+  correction or whitespace update), you can omit the blank line and detailed
+  description.
+
+* End your log message with S.O.B. (Signed-off-by) line. This is done
+  automatically when you use ``git commit -s``. Please see the
+  :ref:`Developer Certificate of Origin <dco>` section for more details here.
+
+* Keep EVERY line under 72 characters. That is, your message should be
+  line-wrapped with line-feeds. However, don't get carried away and wrap it too
+  short either since this also looks funny.
+
+* Detail level: The audience of the commit log message that you should cater to
+  is those familiar with the underlying source code you are modifying, but who
+  are _not_ familiar with the patch you are submitting. They should be able to
+  determine what is being changed and why. Avoid excessive low-level detail.
+  Before submitting, re-read your commit log message with this audience in mind
+  and adjust as needed.
+
+Sending updated patch versions
+------------------------------
+
+It is pretty normal that the first version of a patch you are submitting does
+not get accepted as is, and that you are asked to submit another, improved
+version.
+
+When re-posting such a new version of your patch(es), please always make sure
+to observe the following rules.
+
+* Make an appropriate note that this is a re-submission in the subject line,
+  eg. "[PATCH v2] Add support for feature X". ``git format-patch
+  --subject-prefix="PATCH v2"`` can be used in this case (see the example
+  below).
+
+* Please make sure to keep a "change log", i. e. a description of what you have
+  changed compared to previous versions of this patch. This change log should
+  be added below the "---" line in the patch, which starts the "comment
+  section", i. e. which contains text that does not get included into the
+  actual commit message.
+  Note: it is *not* sufficient to provide a change log in some cover letter
+  that gets sent as a separate message with the patch series. The reason is
+  that such cover letters are not as easily reviewed in our `patchwork queue
+  <http://patchwork.ozlabs.org/project/uboot/list/>`_ so they are not helpful
+  to any reviewers using this tool. Example::
+
+   From: Joe Hacker <jh@hackers.paradise.com>
+   Date: Thu, 1 Jan 2222 12:21:22 +0200
+   Subject: [PATCH 1/2 v3] FOO: add timewarp-support
+
+   This patch adds timewarp-support for the FOO family of processors.
+
+   adapted for the current kernel structures.
+
+   Signed-off-by: Joe Hacker <jh@hackers.paradise.com>
+   Cc: Tom Maintainer <tm@u-boot.custodians.org>
+   ---
+   Changes for v2:
+   - Coding Style cleanup
+   - fixed miscalculation of time-space discontinuities
+   Changes for v3:
+   - fixed compiler warnings observed with GCC-17.3.5
+   - worked around integer overflow in warp driver
+
+    arch/foo/cpu/spacetime.c |	 8 +
+    drivers/warp/Kconfig     |	 7 +
+    drivers/warp/Makefile    |	42 +++
+    drivers/warp/warp-core.c | 255 +++++++++++++++++++++++++
+
+* Make sure that your mailer adds or keeps correct ``In-reply-to:`` and
+  ``References:`` headers, so threading of messages is working and everybody
+  can see that the new message refers to some older posting of the same topic.
+
+Uncommented and un-threaded repostings are extremely annoying and
+time-consuming, as we have to try to remember if anything similar has been
+posted before, look up the old threads, and then manually compare if anything
+has been changed, or what.
+
+If you have problems with your e-mail client, for example because it mangles
+white space or wraps long lines, then please read this article about `Email
+Clients and Patches <http://kerneltrap.org/Linux/Email_Clients_and_Patches>`_.
+
+Notes
+-----
+
+1. U-Boot is Free Software that can redistributed and/or modified under the
+   terms of the `GNU General Public License
+   <http://www.fsf.org/licensing/licenses/gpl.html>`_ (GPL). Currently (August
+   2022) version 2 of the GPL applies. Please see :download:`Licensing
+   <../../Licenses/README>` for details. To allow that later versions of U-Boot
+   may be released under a later version of the GPL, all new code that gets
+   added to U-Boot shall use a "GPL-2.0+" SPDX-License-Identifier.
+
+2. All code must follow the :doc:`codingstyle` requirements.
+
+3. Before sending the patch, you *must* run some form of local testing.
+   Submitting a patch that does not build or function correct is a mistake. For
+   non-trivial patches, either building a number of platforms locally or making
+   use of :doc:`ci_testing` is strongly encouraged in order to avoid problems
+   that can be found when attempting to merge the patch.
+
+4. If you modify existing code, make sure that your new code does not add to
+   the memory footprint of the code. Remember: Small is beautiful! When adding
+   new features follow the guidelines laid out in :doc:`system_configuration`.
+
+Patch Tracking
+--------------
+
+Like some other projects, U-Boot uses `Patchwork <http://patchwork.ozlabs.org/>`_
+to track the state of patches. This is one of the reasons why it is mandatory
+to submit all patches to the U-Boot mailing list - only then they will be
+picked up by patchwork.
+
+At http://patchwork.ozlabs.org/project/uboot/list/ you can find the list of
+open U-Boot patches. By using the "Filters" link (Note: requires JavaScript)
+you can also select other views, for example, to include old patches that have,
+for example, already been applied or rejected.
+
+Note that Patchwork automatically tracks and collects a number of git tags from
+follow-up mails, so it is usually better to apply a patch through the Patchwork
+commandline interface than just manually applying it from a posting on the
+mailing list (in which case you have to do all the tracking and adding of git
+tags yourself). This also obviates the need of a developer to resubmit a patch
+only in order to collect these tags.
+
+A Custodian has additional privileges and can:
+
+* **Delegate** a patch
+
+* **Change the state** of a patch. The following states exist:
+
+   * New
+
+   * Under Review
+
+   * Accepted
+
+   * Rejected
+
+   * RFC
+
+   * Not Applicable
+
+   * Changes Requested
+
+   * Awaiting Upstream
+
+   * Superseeded
+
+   * Deferred
+
+   * Archived
+
+Patchwork work-flow
+^^^^^^^^^^^^^^^^^^^
+
+The following are a "rule of thumb" as to how the states are used in patchwork
+today. Not all states are used by all custodians.
+
+* New: Patch has been submitted to the list, and none of the maintainers has
+  changed it's state since.
+
+* Under Review: A custodian is reviewing the patch currently.
+
+* Accepted: When a patch has been applied to a custodian repository that gets
+  used for pulling from into upstream, they are put into "accepted" state.
+
+* Rejected: Rejected means we just don't want to do what the patch does.
+
+* RFC: The patch is not intended to be applied to any of the mainline
+  repositories, but merely for discussing or testing some idea or new feature.
+
+* Not Applicable: The patch either was not intended to be applied, as it was
+  a debugging or discussion aide that patchwork picked up, or was cross-posted
+  to our list but intended for another project entirely.
+
+* Changes Requested: The patch looks mostly OK, but requires some rework before
+  it will be accepted for mainline.
+
+* Awaiting Upstream: A custodian may have applied this to the ``next`` branch
+  and has not merged yet to master, or has queued the patch up to be submitted
+  to be merged, but has not yet.
+
+* Superseeded: Patches are marked as 'superseeded' when the poster submits a
+  new version of these patches.
+
+* Deferred: Deferred usually means the patch depends on something else that
+  isn't upstream, such as patches that only apply against some specific other
+  repository. This is also used when a patch has been in patchwork for over a
+  year and it is unlikely to be applied as-is.
+
+* Archived: Archiving puts the patch away somewhere where it doesn't appear in
+  the normal pages and needs extra effort to get to.
+
+Apply patches
+^^^^^^^^^^^^^
+
+To apply a patch from the `patchwork queue
+<http://patchwork.ozlabs.org/project/uboot/list/>`_ using ``git``, download the
+mbox file and apply it using::
+
+   git am file
+
+The `openembedded wiki <http://wiki.openembedded.net/>`_ also provides a script
+named `pw-am.sh
+<http://cgit.openembedded.org/cgit.cgi/openembedded/tree/contrib/patchwork/pw-am.sh>`_
+which can be used to fetch an 'mbox' patch from patchwork and git am it::
+
+   usage: pw-am.sh <number>
+   example: 'pw-am.sh 71002' will get and apply the patch from http://patchwork.ozlabs.org/patch/71002/
+
+Update the state of patches
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+You have to register to be able to update the state of patches. You can use the
+Web interface, `pwclient`, or `pwparser`.
+
+pwclient
+^^^^^^^^
+
+The `pwclient` command line tool can be used for example to retrieve patches,
+search the queue or update the state.
+
+All necessary information for `pwclient` is linked from the bottom of
+http://patchwork.ozlabs.org/project/uboot/
+
+Use::
+
+   pwclient help
+
+for an overview on how to use it.
+
+pwparser
+^^^^^^^^
+
+See http://www.mail-archive.com/patchwork@lists.ozlabs.org/msg00057.html
diff --git a/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml
new file mode 100644
index 0000000..4f5404f
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/fwu-mdata-mtd.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/firmware/u-boot,fwu-mdata-sf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: FWU metadata on MTD device without GPT
+
+maintainers:
+ - Masami Hiramatsu <masami.hiramatsu@linaro.org>
+
+properties:
+  compatible:
+    items:
+      - const: u-boot,fwu-mdata-mtd
+
+  fwu-mdata-store:
+    maxItems: 1
+    description: Phandle of the MTD device which contains the FWU medatata.
+
+  mdata-offsets:
+    minItems: 2
+    description: Offsets of the primary and secondary FWU metadata in the NOR flash.
+
+required:
+  - compatible
+  - fwu-mdata-store
+  - mdata-offsets
+
+additionalProperties: false
+
+examples:
+  - |
+    fwu-mdata {
+        compatible = "u-boot,fwu-mdata-mtd";
+        fwu-mdata-store = <&spi-flash>;
+        mdata-offsets = <0x500000 0x530000>;
+    };
diff --git a/doc/usage/cmd/gpio.rst b/doc/usage/cmd/gpio.rst
index f6a5668..ee90213 100644
--- a/doc/usage/cmd/gpio.rst
+++ b/doc/usage/cmd/gpio.rst
@@ -45,6 +45,31 @@
 
 Display the status of one or multiple GPIOs. By default only claimed GPIOs
 are displayed.
+gpio status command output fields are::
+
+    <name>: <function>: <value> [x] <label>
+
+*function* can take the following values:
+
+output
+    pin configured in gpio output, *value* indicates the pin's level
+
+input
+    pin configured in gpio input, *value* indicates the pin's level
+
+func
+    pin configured in alternate function, followed by *label*
+    which shows pinmuxing label.
+
+unused
+    pin not configured
+
+*[x]* or *[ ]* indicate respectively if the gpio is used or not.
+
+*label* shows the gpio label.
+
+Parameters
+----------
 
 -a
     Display GPIOs irrespective of being claimed.
@@ -77,6 +102,23 @@
     => echo $myvar
     0
 
+Show the GPIO status::
+
+    => gpio status
+    Bank GPIOA:
+    GPIOA1: func rgmii-0
+    GPIOA2: func rgmii-0
+    GPIOA7: func rgmii-0
+    GPIOA10: output: 0 [x] hdmi-transmitter@39.reset-gpios
+    GPIOA13: output: 1 [x] red.gpios
+
+    Bank GPIOB:
+    GPIOB0: func rgmii-0
+    GPIOB1: func rgmii-0
+    GPIOB2: func uart4-0
+    GPIOB7: input: 0 [x] mmc@58005000.cd-gpios
+    GPIOB11: func rgmii-0
+
 Configuration
 -------------
 
diff --git a/include/efi_api.h b/include/efi_api.h
index 83c0108..9bb0d44 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -226,6 +226,22 @@
 	EFI_GUID(0x6dcbd5ed, 0xe82d, 0x4c44, 0xbd, 0xa1, \
 		 0x71, 0x94, 0x19, 0x9a, 0xd9, 0x2a)
 
+#define EFI_CONFORMANCE_PROFILES_TABLE_GUID \
+	EFI_GUID(0x36122546, 0xf7ef, 0x4c8f, 0xbd, 0x9b, \
+		 0xeb, 0x85, 0x25, 0xb5, 0x0c, 0x0b)
+
+#define EFI_CONFORMANCE_PROFILES_TABLE_VERSION 1
+
+#define EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID \
+	EFI_GUID(0xcce33c35, 0x74ac, 0x4087, 0xbc, 0xe7, \
+		 0x8b, 0x29, 0xb0, 0x2e, 0xeb, 0x27)
+
+struct efi_conformance_profiles_table {
+	u16 version;
+	u16 number_of_profiles;
+	efi_guid_t	conformance_profiles[];
+} __packed;
+
 struct efi_capsule_header {
 	efi_guid_t capsule_guid;
 	u32 header_size;
diff --git a/include/efi_loader.h b/include/efi_loader.h
index b0d6fff..545ba06 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -531,8 +531,10 @@
 void efi_try_purge_kaslr_seed(void *fdt);
 /* Called by bootefi to make console interface available */
 efi_status_t efi_console_register(void);
-/* Called by efi_init_obj_list() to initialize efi_disks */
+/* Called by efi_init_early() to add block devices when probed */
 efi_status_t efi_disk_init(void);
+/* Called by efi_init_obj_list() to proble all block devices */
+efi_status_t efi_disks_register(void);
 /* Called by efi_init_obj_list() to install EFI_RNG_PROTOCOL */
 efi_status_t efi_rng_register(void);
 /* Called by efi_init_obj_list() to install EFI_TCG2_PROTOCOL */
@@ -1051,6 +1053,13 @@
 efi_status_t efi_esrt_register(void);
 
 /**
+ * efi_ecpt_register() - Install the ECPT system table.
+ *
+ * Return: status code
+ */
+efi_status_t efi_ecpt_register(void);
+
+/**
  * efi_esrt_populate() - Populates the ESRT entries from the FMP instances
  * present in the system.
  * If an ESRT already exists, the old ESRT is replaced in the system table.
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 5cfff8c..b8fb270 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -385,6 +385,23 @@
 	help
 	  Enabling this option creates the ESRT UEFI system table.
 
+config EFI_ECPT
+	bool "Enable the UEFI ECPT generation"
+	default y
+	help
+	  Enabling this option created the ECPT UEFI table.
+
+config EFI_EBBR_2_0_CONFORMANCE
+	bool "Add the EBBRv2.0 conformance entry to the ECPT table"
+	depends on EFI_ECPT
+	depends on EFI_LOADER_HII
+	depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV
+	depends on EFI_RNG_PROTOCOL || !DM_RNG
+	depends on EFI_UNICODE_COLLATION_PROTOCOL2
+	default y
+	help
+	  Enabling this option adds the EBBRv2.0 conformance entry to the ECPT UEFI table.
+
 config EFI_RISCV_BOOT_PROTOCOL
 	bool "RISCV_EFI_BOOT_PROTOCOL support"
 	default y
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f54c244..e187d2a 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -76,6 +76,7 @@
 obj-$(CONFIG_EFI_RISCV_BOOT_PROTOCOL) += efi_riscv.o
 obj-$(CONFIG_EFI_LOAD_FILE2_INITRD) += efi_load_initrd.o
 obj-$(CONFIG_EFI_SIGNATURE_SUPPORT) += efi_signature.o
+obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
 
 EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
 $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
diff --git a/lib/efi_loader/efi_conformance.c b/lib/efi_loader/efi_conformance.c
new file mode 100644
index 0000000..a49aae9
--- /dev/null
+++ b/lib/efi_loader/efi_conformance.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ *  EFI conformance profile table
+ *
+ *  Copyright (C) 2022 Arm Ltd.
+ */
+
+#include <common.h>
+#include <efi_loader.h>
+#include <log.h>
+#include <efi_api.h>
+#include <malloc.h>
+
+static const efi_guid_t efi_ecpt_guid = EFI_CONFORMANCE_PROFILES_TABLE_GUID;
+static const efi_guid_t efi_ebbr_2_0_guid =
+	EFI_CONFORMANCE_PROFILE_EBBR_2_0_GUID;
+
+/**
+ * efi_ecpt_register() - Install the ECPT system table.
+ *
+ * Return: status code
+ */
+efi_status_t efi_ecpt_register(void)
+{
+	int num_entries = 0;
+	struct efi_conformance_profiles_table *ecpt;
+	efi_status_t ret;
+	size_t ecpt_size;
+
+	ecpt_size = num_entries * sizeof(efi_guid_t)
+		+ sizeof(struct efi_conformance_profiles_table);
+	ret = efi_allocate_pool(EFI_BOOT_SERVICES_DATA, ecpt_size,
+				(void **)&ecpt);
+
+	if (ret != EFI_SUCCESS) {
+		log_err("Out of memory\n");
+
+		return ret;
+	}
+
+	if (CONFIG_IS_ENABLED(EFI_EBBR_2_0_CONFORMANCE))
+		guidcpy(&ecpt->conformance_profiles[num_entries++],
+			&efi_ebbr_2_0_guid);
+
+	ecpt->version = EFI_CONFORMANCE_PROFILES_TABLE_VERSION;
+	ecpt->number_of_profiles = num_entries;
+
+	/* Install the ECPT in the system configuration table. */
+	ret = efi_install_configuration_table(&efi_ecpt_guid, (void *)ecpt);
+	if (ret != EFI_SUCCESS) {
+		log_err("Failed to install ECPT\n");
+		efi_free_pool(ecpt);
+
+		return ret;
+	}
+
+	log_debug("ECPT created\n");
+
+	return EFI_SUCCESS;
+}
diff --git a/lib/efi_loader/efi_console.c b/lib/efi_loader/efi_console.c
index 3164fd4..ee9dc6b 100644
--- a/lib/efi_loader/efi_console.c
+++ b/lib/efi_loader/efi_console.c
@@ -987,12 +987,14 @@
 	efi_cin_check();
 
 	if (!key_available) {
+		memset(key_data, 0, sizeof(struct efi_key_data));
 		ret = EFI_NOT_READY;
 		goto out;
 	}
 	/*
 	 * CTRL+A - CTRL+Z have to be signaled as a - z.
 	 * SHIFT+CTRL+A - SHIFT+CTRL+Z have to be signaled as A - Z.
+	 * CTRL+\ - CTRL+_ have to be signaled as \ - _.
 	 */
 	switch (next_key.key.unicode_char) {
 	case 0x01 ... 0x07:
@@ -1005,6 +1007,9 @@
 			next_key.key.unicode_char += 0x40;
 		else
 			next_key.key.unicode_char += 0x60;
+		break;
+	case 0x1c ... 0x1f:
+			next_key.key.unicode_char += 0x40;
 	}
 	*key_data = next_key;
 	key_available = false;
diff --git a/lib/efi_loader/efi_device_path_to_text.c b/lib/efi_loader/efi_device_path_to_text.c
index 6c428ee..9062058 100644
--- a/lib/efi_loader/efi_device_path_to_text.c
+++ b/lib/efi_loader/efi_device_path_to_text.c
@@ -190,13 +190,14 @@
 		struct efi_device_path_nvme *ndp =
 			(struct efi_device_path_nvme *)dp;
 		u32 ns_id;
-		int i;
 
 		memcpy(&ns_id, &ndp->ns_id, sizeof(ns_id));
 		s += sprintf(s, "NVMe(0x%x,", ns_id);
-		for (i = 0; i < sizeof(ndp->eui64); ++i)
+
+		/* Display byte 7 first, byte 0 last */
+		for (int i = 0; i < 8; ++i)
 			s += sprintf(s, "%s%02x", i ? "-" : "",
-				     ndp->eui64[i]);
+				     ndp->eui64[i ^ 7]);
 		s += sprintf(s, ")");
 
 		break;
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index f269abf..5feeb52 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -760,3 +760,20 @@
 
 	return EFI_SUCCESS;
 }
+
+/**
+ * efi_disks_register() - ensure all block devices are available in UEFI
+ *
+ * The function probes all block devices. As we store UEFI variables on the
+ * EFI system partition this function has to be called before enabling
+ * variable services.
+ */
+efi_status_t efi_disks_register(void)
+{
+	struct udevice *dev;
+
+	uclass_foreach_dev_probe(UCLASS_BLK, dev) {
+	}
+
+	return EFI_SUCCESS;
+}
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 751beda..c633fcd 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -246,6 +246,14 @@
 	/* Set up console modes */
 	efi_setup_console_size();
 
+	/*
+	 * Probe block devices to find the ESP.
+	 * efi_disks_register() must be called before efi_init_variables().
+	 */
+	ret = efi_disks_register();
+	if (ret != EFI_SUCCESS)
+		goto out;
+
 	/* Initialize variable services */
 	ret = efi_init_variables();
 	if (ret != EFI_SUCCESS)
@@ -266,6 +274,12 @@
 	if (ret != EFI_SUCCESS)
 		goto out;
 
+	if (IS_ENABLED(CONFIG_EFI_ECPT)) {
+		ret = efi_ecpt_register();
+		if (ret != EFI_SUCCESS)
+			goto out;
+	}
+
 	if (IS_ENABLED(CONFIG_EFI_ESRT)) {
 		ret = efi_esrt_register();
 		if (ret != EFI_SUCCESS)
diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
index 10666dc..d565f32 100644
--- a/lib/efi_loader/helloworld.c
+++ b/lib/efi_loader/helloworld.c
@@ -29,24 +29,66 @@
 static struct efi_boot_services *boottime;
 static struct efi_simple_text_output_protocol *con_out;
 
+/*
+ * Print an unsigned 32bit value as decimal number to an u16 string
+ *
+ * @value:	value to be printed
+ * @buf:	pointer to buffer address
+ *		on return position of terminating zero word
+ */
+static void uint2dec(u32 value, u16 **buf)
+{
+	u16 *pos = *buf;
+	int i;
+	u16 c;
+	u64 f;
+
+	/*
+	 * Increment by .5 and multiply with
+	 * (2 << 60) / 1,000,000,000 = 0x44B82FA0.9B5A52CC
+	 * to move the first digit to bit 60-63.
+	 */
+	f = 0x225C17D0;
+	f += (0x9B5A52DULL * value) >> 28;
+	f += 0x44B82FA0ULL * value;
+
+	for (i = 0; i < 10; ++i) {
+		/* Write current digit */
+		c = f >> 60;
+		if (c || pos != *buf)
+			*pos++ = c + '0';
+		/* Eliminate current digit */
+		f &= 0xfffffffffffffff;
+		/* Get next digit */
+		f *= 0xaULL;
+	}
+	if (pos == *buf)
+		*pos++ = '0';
+	*pos = 0;
+	*buf = pos;
+}
+
 /**
  * print_uefi_revision() - print UEFI revision number
  */
 static void print_uefi_revision(void)
 {
-	u16 rev[] = u"0.0.0";
+	u16 rev[13] = {0};
+	u16 *buf = rev;
+	u16 digit;
 
-	rev[0] = (systable->hdr.revision >> 16) + '0';
-	rev[4] = systable->hdr.revision & 0xffff;
-	for (; rev[4] >= 10;) {
-		rev[4] -= 10;
-		++rev[2];
+	uint2dec(systable->hdr.revision >> 16, &buf);
+	*buf++ = '.';
+	uint2dec(systable->hdr.revision & 0xffff, &buf);
+
+	/* Minor revision is only to be shown if non-zero */
+	digit = *--buf;
+	if (digit == '0') {
+		*buf = 0;
+	} else {
+		*buf++ = '.';
+		*buf = digit;
 	}
-	/* Third digit is only to be shown if non-zero */
-	if (rev[4])
-		rev[4] += '0';
-	else
-		rev[3] = 0;
 
 	con_out->output_string(con_out, u"Running on UEFI ");
 	con_out->output_string(con_out, rev);
diff --git a/lib/efi_selftest/efi_selftest_miniapp_exception.c b/lib/efi_selftest/efi_selftest_miniapp_exception.c
index 79f9a67..a9ad381 100644
--- a/lib/efi_selftest/efi_selftest_miniapp_exception.c
+++ b/lib/efi_selftest/efi_selftest_miniapp_exception.c
@@ -9,6 +9,7 @@
 
 #include <common.h>
 #include <efi_api.h>
+#include <host_arch.h>
 
 /*
  * Entry point of the EFI application.
@@ -33,10 +34,16 @@
 	asm volatile (".word 0xe7f7defb\n");
 #elif defined(CONFIG_RISCV)
 	asm volatile (".word 0xffffffff\n");
-#elif defined(CONFIG_SANDBOX)
-	asm volatile (".word 0xffffffff\n");
 #elif defined(CONFIG_X86)
 	asm volatile (".word 0xffff\n");
+#elif defined(CONFIG_SANDBOX)
+#if (HOST_ARCH == HOST_ARCH_ARM || HOST_ARCH == HOST_ARCH_AARCH64)
+	asm volatile (".word 0xe7f7defb\n");
+#elif (HOST_ARCH == HOST_ARCH_RISCV32 || HOST_ARCH == HOST_ARCH_RISCV64)
+	asm volatile (".word 0xffffffff\n");
+#elif (HOST_ARCH == HOST_ARCH_X86 || HOST_ARCH == HOST_ARCH_X86_64)
+	asm volatile (".word 0xffff\n");
+#endif
 #endif
 	con_out->output_string(con_out, u"Exception not triggered.\n");
 	return EFI_ABORTED;
diff --git a/lib/uuid.c b/lib/uuid.c
index 284f811..465e1ac 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -220,6 +220,10 @@
 		"TCG2 Final Events Table",
 		EFI_TCG2_FINAL_EVENTS_TABLE_GUID,
 	},
+	{
+		"EFI Conformance Profiles Table",
+		EFI_CONFORMANCE_PROFILES_TABLE_GUID,
+	},
 #ifdef CONFIG_EFI_RISCV_BOOT_PROTOCOL
 	{
 		"RISC-V Boot",